Well, that's one way to load files from the hard disk...
-
So, this application I've been working with for the past few months, one of the things I learned early on is: for the legacy page requests, that get routed to a COM dll written in VB6, build up XML, transform that via an XSLT, and then that gets written back to the client. Bad enough to start with, since I can't figure out why they didn't go with just ASP, or considering the time frame most of this was done, .Net. These XSLTs are loaded via MSXML with an HTTP request, which I thought was bad enough, but it gets worse.
One of the things we currently lack in this application are any sort of analytics. We plan on redoing the legacy code soon, and it would be good to know what parts of the application are actually used. I requested some log files be pulled from the web servers this morning to do some data mining on to see what I can find. A few quick greps on the file give me that roughly a quarter of the requests the web servers get are from the local application. Then I look a bit closer: The IP that those XSLT requests come from isn't loopback, or the server's local IP, it's the server's IP address.
So, with no caching whatsoever, most client requests result in 3 requests for XSL files. These are done over HTTPS, so the server build up an SSL session with itself, via our gateway router, pull the XSL, and then tear down the SSL session. 3 times. For. Every. Request.
This application is like a fractal of suck.
-
@bardofspoons42 said:
So, this application I've been working with for the past few months, one of the things I learned early on is: for the legacy page requests, that get routed to a COM dll written in VB6, build up XML, transform that via an XSLT, and then that gets written back to the client. Bad enough to start with, since I can't figure out why they didn't go with just ASP, or considering the time frame most of this was done, .Net. These XSLTs are loaded via MSXML with an HTTP request, which I thought was bad enough, but it gets worse.One of the things we currently lack in this application are any sort of analytics. We plan on redoing the legacy code soon, and it would be good to know what parts of the application are actually used. I requested some log files be pulled from the web servers this morning to do some data mining on to see what I can find. A few quick greps on the file give me that roughly a quarter of the requests the web servers get are from the local application. Then I look a bit closer: The IP that those XSLT requests come from isn't loopback, or the server's local IP, it's the server's IP address.
So, with no caching whatsoever, most client requests result in 3 requests for XSL files. These are done over HTTPS, so the server build up an SSL session with itself, via our gateway router, pull the XSL, and then tear down the SSL session. 3 times. For. Every. Request.
This application is like a fractal of suck.
Quick solution to speed up the I/O: RAMDRIVE! Plus you could do lots of interesting touch-up/injection whenever you perform the initial load every time you reboot the server. Foolproof!
-
@bardofspoons42 said:
So, with no caching whatsoever, most client requests result in 3 requests for XSL files. These are done over HTTPS, so the server build up an SSL session with itself, via our gateway router, pull the XSL, and then tear down the SSL session. 3 times. For. Every. Request.
Only 3? Last webapp I worked on, the outsource devs had used their own database library for everything, and issues with load were starting to pop up ("too many connections" errors and such).
The problem? The database lib would abstract things so that the end-user didn't have to know SQL syntax. It would build it for them based on passed-in bits of.. uh, well, SQL syntax, just without the keywords like SELECT and WHERE.
Anyway, so the start_querie() function would open a new connection, concat all the user-supplied data together, then.. just close the connection without reading anything. The subsequent read_datas() function would do this same thing, but add a LIMIT clause to select just one row, then read that row and return it.
But what if you needed more than one row? You of course used get_all_datas(), which simply called read_datas() in a while(1) loop till it threw any exception. Creating a new database connection for each and every row of data. In many cases, get_all_datas() was called multiple times for no reason, often even on inserts (where it would simply loop until the script timed out, still creating connections for no reason). Another common pattern when one row was needed from a table with thousands of rows was to just call get_all_datas("*,"tbl_alldatatable"), then scan the array for the needed element.
-
@SamC said:
The subsequent read_datas() function would do this same thing, but add a LIMIT clause to select just one row, then read that row and return it.
But what if you needed more than one row? You of course used get_all_datas(), which simply called read_datas() in a while(1) loop till it threw any exception.
I like the use of the non-word "datas". And "all datas" is just gravy. It's sort of like the Southern expression "all y'all," only stupid.
-
@SamC said:
Creating a new database connection for each and every row of data.
That's why God created connection pools. Looking at the code developers think they open/close connections but really they just recycle existing ones.
-
@FrostCat said:
@SamC said:
The subsequent read_datas() function would do this same thing, but add a LIMIT clause to select just one row, then read that row and return it.
But what if you needed more than one row? You of course used get_all_datas(), which simply called read_datas() in a while(1) loop till it threw any exception.
I like the use of the non-word "datas". And "all datas" is just gravy.
It's sort of like the Southern expression "all y'all," only stupid.Oh, that is only but a taste. In addition to "datas", it was also spelled "data", "datea", "dates", and of course there was no consistency either for whether a function would "get" data, "read" it, "fetch" it, "got" it, or even, daresay, "reab" it.
@Ronald said:
@SamC said:
Creating a new database connection for each and every row of data.
That's why God created connection pools. Looking at the code developers think they open/close connections but really they just recycle existing ones.
Connection pools? Nah, I got work to do, no time to go for a swim.
Anyway, yes, this app was PHP, and in PDO you have to explicitly declare you want a persistent connection, because... Uh, well, because PHP.
Actually, I don't even know if the ancient legacy "mysql_" API (of course they were using that) supports this feature, considering it doesn't even cover the bare necessities like parameterized queries..
-
@SamC said:
Actually, I don't even know if the ancient legacy "mysql_" API (of course they were using that) supports this feature, considering it doesn't even cover the bare necessities like parameterized queries..
Since you did not take 10 seconds to google that up I'm putting the URL without a proper link. That should teach you.
-
@SamC said:
Anyway, yes, this app was PHP, and in PDO you have to explicitly declare you want a persistent connection, because... Uh, well, because PHP.
Actually, I don't even know if the ancient legacy "mysql_" API (of course they were using that) supports this feature, considering it doesn't even cover the bare necessities like parameterized queries..
Usually persistent connections are a bad idea in PHP, anyway. Generally you don't need connection pools, but if you do, just use a standalone daemon.
-
@Ronald said:
@SamC said:
Actually, I don't even know if the ancient legacy "mysql_" API (of course they were using that) supports this feature, considering it doesn't even cover the bare necessities like parameterized queries..
Since you did not take 10 seconds to google that up I'm putting the URL without a proper link. That should teach you.Ah, so it does.
(And I didn't bother to look that up [or right-click and hit open-link], simply because I'm not an Archeology major.)
In the end, I got the approval to just start over from scratch. It wasn't a hard sell at all.
-
@SamC said:
@Ronald said:
@SamC said:
Actually, I don't even know if the ancient legacy "mysql_" API (of course they were using that) supports this feature, considering it doesn't even cover the bare necessities like parameterized queries..
Since you did not take 10 seconds to google that up I'm putting the URL without a proper link. That should teach you.Ah, so it does.
(And I didn't bother to look that up [or right-click and hit open-link], simply because I'm not an Archeology major.)
In the end, I got the approval to just start over from scratch. It wasn't a hard sell at all.
For over 15 years (and counting) lots of porn, lots of forums, lots of shopping carts have been running on mysql_ commands. You may dislike it and jerk off all you want to the latest and greatest persistence API but that does not change the fact that in the big scheme of things that awful technology is a success and yours is not.
-
@SamC said:
Oh, that is only but a taste. In addition to "datas", it was also spelled "data", "datea", "dates"…
- data_of_query()
- average_datea()
- assign_datea_new_value()
- read_datam()
- remove_datea_where()
Oh, wait, that’s wrong…
PHP: mysql_pconnect - Manual
