You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have this site which is super media intensive. The closest thing I can say that is close to what we are doing which all of us can reference quickly is Amazon. Not an e-commerce site though. In our case, since we have a lot of media interconnected and this package has served the media upload process very very well, I am looking at improving the performance of the site by removing the media table.
Currently, here's a snapshot of how the code runs in production courtesy of https://inspector.dev/.
This is just a snapshot of half of the stack which contributes to the overall time the page takes to load. Looking at this, timeline there are multiple queries made to the media table. So if say we are fetching item x by user y and user y has other items that we would like to display as related, then it becomes an issue as the memory consumption goes up then the CPU taps out even though we are running in a containerized environment.
Using the Laravel accessors method, a typical model would have the following three calls:
$this->getFirstMediaUrl('cover_images') // The cover image
$this->getFirstMediaUrl('media_files') // The media file URL since it's tricky to construct the URL on the Vue.js side
$this->getMedia('media_files')->first() // The media file itself for other file details.
Thus I thought to make a clone of this package and refactor is such that, instead of having a media table, the file references are saved directly to the table itself. Say we have a JSON field called media then we store all that could have been stored in the media table entry there. That way, when a query is made, it happens at once and that single model has everything it needs in memory without doing additional queries. I have no qualms about adding a media field to each table one by one.
As such, what I am asking for is, is there a way to get the way this package is architectured so that I can only change the database persistence part without having to change anything else cause all the methods provided are useful as they are. It's just the persistence part that I need to change. Pointers as to where to start would be great for purposes of efficiency.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
I have this site which is super media intensive. The closest thing I can say that is close to what we are doing which all of us can reference quickly is Amazon. Not an e-commerce site though. In our case, since we have a lot of media interconnected and this package has served the media upload process very very well, I am looking at improving the performance of the site by removing the media table.
Currently, here's a snapshot of how the code runs in production courtesy of https://inspector.dev/.

This is just a snapshot of half of the stack which contributes to the overall time the page takes to load. Looking at this, timeline there are multiple queries made to the media table. So if say we are fetching item x by user y and user y has other items that we would like to display as related, then it becomes an issue as the memory consumption goes up then the CPU taps out even though we are running in a containerized environment.
Using the Laravel accessors method, a typical model would have the following three calls:
Thus I thought to make a clone of this package and refactor is such that, instead of having a media table, the file references are saved directly to the table itself. Say we have a JSON field called
media
then we store all that could have been stored in the media table entry there. That way, when a query is made, it happens at once and that single model has everything it needs in memory without doing additional queries. I have no qualms about adding a media field to each table one by one.As such, what I am asking for is, is there a way to get the way this package is architectured so that I can only change the database persistence part without having to change anything else cause all the methods provided are useful as they are. It's just the persistence part that I need to change. Pointers as to where to start would be great for purposes of efficiency.
Thanks.
Beta Was this translation helpful? Give feedback.
All reactions